…posture flag, not a tenant-isolation primitive

The previous copy ("admins are treated like regular users for workspace
access ... only see items they have explicit permission to access") read
to multiple security-report submitters as a hard access-control
enforcement at every API endpoint, including a tenant-isolation primitive
between admins. It isn't, and was never designed to be.

Rewrite the description to make the actual scope explicit:

- Lists the three converging reasons the flag exists (performance,
  UI clutter, compliance posture for jurisdictions with stronger
  labour-protection law) — none of which is tenant isolation.
- Calls out by name that per-id direct-access endpoints are
  intentionally not gated by this flag and were never designed to be,
  to pre-empt the recurring "missed migration" misreading.
- Restates the architectural invariant that Open WebUI is single-tenant
  and admin is root-equivalent (DB / env / server / Functions / Tools),
  with the explicit note that for genuine cross-tenant isolation the
  supported pattern is separate instances.
- Anchors the analogy to the analytics-page visibility toggle, which
  follows the same "hide from admin's UI surfaces, do not change the
  underlying data semantics" pattern.

No code change, no behavioural change — only documentation copy. Closes
the doc side of the recurring confusion that produced
GHSA-8h93-446x-834j (and the earlier related reads).

…on across the cluster

…ployments (#9)

Two clarifications, both surfacing requirements that were implicit before:

- features/open-terminal/advanced/multi-user.md: add a top-of-page
  :::danger callout that running open-terminal without one of the two
  isolation modes is not a supported configuration for multi-user
  Open WebUI. Strengthen the existing Option 1 warning to make the
  shared-network-namespace caveat explicit (per-user file isolation
  in Option 1 does NOT extend to per-user network isolation; bound
  ports are reachable across users from the proxy URL). Point at
  Option 2 (per-user containers via Terminals) for untrusted-user
  deployments and TERMINAL_PROXY_HEADERS for additional lockdown.

- reference/env-configuration.mdx: rewrite the TERMINAL_PROXY_HEADERS
  entry. The previous example used "sandbox allow-scripts allow-same-
  origin" which nullifies the sandbox by re-granting same-origin
  access — exactly the keyword that lets attacker-uploaded HTML reach
  localStorage. Replace with a working sandbox CSP (no allow-same-
  origin) plus nosniff/referrer/frame-options, and add a security
  note explaining the default-permissive choice (legitimate dev/
  tooling JS use cases) plus when operators should layer the sandbox
  on top.

0.9.5